The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
A known network management approach comprises simple network management protocol (SNMP) which allows exchange of management information between network devices. SNMP is described, for example, in “A Simple Network Management Protocol (SNMP)” which is available at the time of writing on the file “rfc1157.html” and subsequent Requests for Comments (RFC) in the directory “rfc” of the domain “ietf.org” of the World Wide Web. SNMP is well understood by the skilled reader and so is described only in summary here with reference to FIG. 1 which is a block diagram showing a network using SNMP. A network management system (NMS) 100 comprises a network computer device on which is resident a management application 102 which communicates via a network 104 with one or more managed network elements 106 for example a router, switch, host or other managed network device. In particular, the management application 102 receives operational, status, statistical and other information from and relating to the network element 106, which information is obtained by an SNMP agent 108 on the network element 106 which stores the information as a management information base (MIB) 110.
MIBs are well understood by the skilled reader and described, for example, in “Management Information Base for Network Management of TCP/IP-based-internet: MIB-II” which is available at the time of writing on the file “rfc1213.txt” in the directory “rfc” of the domain “ietf.org” of the World Wide Web. In particular the information is ordered by treating it as objects each having an object identifier (OID) stored in a hierarchy 112. The OIDs are represented in a tree structure, each point on the tree either terminating at a branch 114 or at a leaf node 116 pointing to a variable value 118 for the object. The OID is expressed in the form .x.y.z . . . signifying the route to the respective node from the root of the tree. The information objects can take any appropriate form for example configuration information, interface information, event information, alarm information and so forth and may take either a scalar or a table value.
The MIB is populated according to a scheme or process managed by the SNMP agent 108. However when the network element 106 reloads, for example upon a reboot, some values must be obtained again and reloaded into the MIB. As a result, extra coding and complexity are required by the network management system.
An example of this arises in the case of the information object type “if Index” value assigned to identify an interface. The MIB in this case is “The Interfaces Group MIB” which is available at the time of writing on the file “rfc2863.txt” in the directory “rfc” of the domain “ietf.org” of the World Wide Web. This specifies:
ifIndex OBJECT-TYPESYNTAX InterfaceIndexMAX-ACCESS read-onlySTATUS currentDESCRIPTION                “A unique value, greater than zero, for each interface. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization.”        
::= { ifEntry 1 }
In view of the possibility of re-initialisation of ifIndex, an ifIndex persistence feature has been implemented as described in “Configuring SNMP ifIndex Persistence” which is available at the time of writing on the file “ifIndex.htm” in the directory “univercd/cc/td/doc/product/lan/cat6000/122sx/swcg” of the domain “cisco.com” of the World Wide Web. In particular a command is entered, for example on the command line interface (CLI) of type:    router (config)# snmp-server ifIndex persist. Accordingly, known solutions only provide SNMP MIB variable persistence for specific features requiring individual and potentially specifically tailored command input per-feature.